Cryptosystems perform cryptography to transform plaintext into ciphertext so that only an authorized receiver can transform the ciphertext back into the original plaintext. Encryption or enciphering is the process that transforms plaintext into ciphertext. Decryption or deciphering is the process that transforms ciphertext into plaintext.
A parameter called an encryption key is employed by a cryptosystem to prevent the plaintext from being easily revealed by an unauthorized person. A sender transforms a given plaintext into one of a large variety of possible ciphertexts selected by the specific encryption key. A receiver of the ciphertext deciphers the ciphertext by employing a parameter referred to as a decryption key. In a public-key cryptosystem, the encryption key is made public while the decryption key is kept secret. Therefore, in public key cryptosystems, the decryption key must be computationally infeasible to deduce from the encryption key. In a private-key cryptosystem, the sender and the receiver typically share a common key that is used for both enciphering and deciphering. In such a private-key cryptosystem, the common key is alterable and must be kept secret.
Private-key cryptosystems are typically implemented as block cipher cryptosystems or stream cipher cryptosystems. Block cipher cryptosystems divide the plaintext into blocks and encipher each block independently using a stateless transform. In block cipher cryptosystems, if one fixed common private-key is employed to encipher different occurrences of a particular plaintext block, all of these occurrences are encrypted into identical corresponding ciphertext blocks. Therefore, the block size is preferably selected to be large enough to frustrate attacks from a cryptanalyst, which analyzes the occurrence frequencies of various patterns among the ciphertext blocks. Example block sizes are 64 bits and 128 bits.
In stream cipher cryptosystems, the plaintext is typically encrypted on a bit-by-bit or word-by-word basis using a stateful transform that evolves as the encryption progresses. In encrypting the plaintext binary data sequence for transmission as a ciphertext binary data sequence, the common private-key is a parameter that typically controls a pseudo-random number generator to create a long sequence of binary data referred to as a keystream. The stream cipher cryptosystem includes a cryptographic combiner, which combines the keystream with the plaintext sequence. The cryptographic combiner is typically implemented with exclusive-or (XOR) bit-wise logic gates, which perform bit-wise modulo-2 addition. The cryptographic combiner produces the ciphertext. At the receiver, the common private-key controls a receiver pseudo-random number generator to produce a decryption keystream. The decryption keystream is combined with a decryption combiner to decrypt the ciphertext to provide the plaintext to the receiver.
One problem with stream cipher cryptosystems is the difficulty of generating a long, statistically uniform, and unpredictable sequence of binary data in the keystream from a short and random key. Such sequences are desirable in the keystream in cryptography to make it impossible, given a reasonable segment of its data and sufficient computer resources, to find out more about the sequences. Because of the difficulty in producing sequences that are completely unpredictable, it is desirable to have a combiner that reveals as little as possible about the keystream to an adversary having knowledge of the plaintext corresponding to some ciphertext (a so called “known plaintext attack”).
There are four general requirements for cryptographically secure keystream pseudo-random number generators. First, the period of a keystream must be large enough to accommodate the length of the transmitted message. Second, the keystream output bits must have good statistical properties (e.g. values are uniformly distributed). Third, the keystream output bits must be easy to generate. Fourth, the keystream output bits must be hard to predict. For example, given the pseudo-random number generator and the first N output bits, a(0), a(1), . . . , a(N−1), it should be computationally infeasible to predict the (N+1)th bit a(N) in a sequence with better than a 50-50 chance. In otherwords, a cryptanalyst should not be able to generate other forward bits or backward bits if presented with a given portion of the keystream output sequence.
The receiver decryption combiner operation must be the inverse of the sender encryption combiner. The most common combiner operation is bit-wise XOR. One problem with the XOR combiner operation is that, if some or all of the plaintext of a message is known, the known plaintext can be combined with the associated ciphertext to reveal all or part of the keystream. This could enable one to read other messages sent under the same key, or to forge ciphertext messages that will decrypt to whatever plaintext is desired by an adversary. A second problem with the XOR combiner operation is that an accidental double encryption causes all of the plaintext to become visible. Another problem with the XOR combiner operation is that two ciphertexts using the same key can be XORed together by a cryptanalyst to eliminate the keystream and leave the XOR of two plaintexts. The low entropy of languages, such as the English language, allows for the XOR of two plaintexts to be resolved into its two original plaintext messages. Furthermore, if the keystream period is smaller than a message, this type of cryptanalysis also can be performed by dividing a ciphertext message into portions the size of the keystream and XORing the portions together to eliminate the keystream and leave the XOR of the plaintext portions.
Another problem with the XOR combiner operation is that it allows an adversary to manipulate the contents of the message with only trivial information about its structure. If an adversary wants to change some bit(s) in the received plaintext, all that need be done is to intercept the ciphertext message, invert the ciphertext bit(s) corresponding to the plaintext bit(s) the adversary wants to change, and then send the message on to the receiver. The only knowledge that an adversary needs is the location within the message of the bit(s) to be changed.
Similar problems as those discussed above exist in all linear combiners, although typically not as severe as in an XOR combiner. Some very complex cryptographic combiners solve some of the above-problems. These very complex cryptographic combiners are, however, quite expensive in terms of time and/or hardware resources. One example cryptographic combiner in this very complex category is a permutation table combiner. The permutation table is required to have a table the size of the plaintext alphabet. For example, if the plaintext unit size is 32 bits, the permutation table needs to be 16 gigabytes. On the other hand, if the plaintext unit size is 8 bits, the permutation table size is only required to be 256 bytes, but encrypting 8 bit plaintext units is typically 4 times slower than using 32 bit plaintext units. In addition, the smaller plaintext unit size limits the amount of plaintext diffusion. Plaintext diffusion means that plaintext bits can affect the encryption of other plaintext bits. Diffusion is desirable because it makes cryptanalysis more difficult. The XOR combiner operation has no plaintext diffusion.
For reasons stated above and for other reasons presented in greater detail in the Description of the Preferred Embodiments section of the present specification, a cryptographic combiner is desired for stream cipher cryptosystems wherein known plaintext can not be combined with associated ciphertext to reveal the keystream, and wherein accidental double encryption does not remove the keystream from the combined output bits. In addition, there is a need for a cryptographic combiner where the same keystream cannot be used to combine two ciphertext to eliminate the keystream and leave the combiner operation of the two original plaintext messages. Such a desired cryptographic combiner should be relatively inexpensive in time and hardware resources.